IBIS Macromodel Task Group Meeting date: 11 June 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai Chi-te Chen * Liwei Zhao Alaeddin Aydiner * Sai Zhou Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: * Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Sai Zhou introduced himself to the group. He works on developing internal EDA tools at Intel. He joined the meeting to discuss some questions about PAM4 parameters. - Michael said he would propose tabling the [Clock Pins] update. ------------- Review of ARs: None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 21st meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: Fixing [Clock Pins]: Michael moved to table this topic. He said he had more pressing near term questions for ATM including Usage In vs. Info and the use of [Ramp] and Ts4file. Curtis seconded the motion. There were no objections. Arpad moved this item to the tabled topics. PAM4_Mapping Usage questions: Sai said that PAM4_Mapping allowing both Usage In and Info could cause confusion. He asked whether we had to worry about the tool and the model each thinking they had to deal with mapping. Fangyi said the definition states: "Tells the EDA tool how to map voltage levels to two-bit PAM4 symbols" Fangyi said the PAM4_Mapping information is used by the tool. Fangyi noted that the input to a PAM4 Tx model is a 4-level waveform that has been generated by the tool. It's the tool that has to know how to convert the two-bit PAM4 symbol to a voltage level. Michael asked why we allow Usage In for this parameter at all. Fangyi said that typically it would be Usage Info, but you might have a model that wanted to handle some non-linearity or noise modeling differently according to the PAM4_Mapping. In that case, the parameter (in the .ami file) provides a list of the possible values, the user selects one, and it is passed into the model. However, the model should not be using the PAM4_Mapping parameter's value to redo the mapping. The mapping is handled by the tool. Arpad noted that newer, more general, PAMn parameters had superseded the older PAM4 parameters. He asked whether our intent had been to deprecate the older PAM4 parameters altogether. Ambrish noted that Modulation and PAM4_Mapping are the only Reserved parameters that allow both Usage In and Usage Info. Modulation_Levels, the new PAMn parameter analogous to Modulation, only allows Usage In. It is clear that the tool needs to know the value of Modulation, even though it's Usage In. Ambrish also noted that with the new PAMn parameters we intentionally left mapping up to the EDA tool. There is no Reserved Parameter analogous to the older PAM4_Mapping. Liwei and Sai explained that in their internal AMI model they use the PAM4_Mapping information to map voltage levels back to binary so they can do internal BER calculations. Fangyi said this is fine, but it's internal to the to the model. Ambrish noted that on page 281, of IBIS 7.2, it is "highly recommended" that model makers use the newer PAMn parameters. Michael said that model makers are sometimes constrained by the particular model development tool they're using. Unless they're writing models from scratch they have to live within the confines of the tools they're using to develop AMI models. Fangyi and Curtis noted that the model Liwei and Sai were describing wouldn't work with the PAMn Reserved Parameters, as there is no mapping parameter. Arpad asked whether we should add clarifying language stating that Usage In parameters are for the model, but for Reserved Parameters the EDA tool is also able to use the information. Ambrish suggested that we not open a can of worms, since the PAM4 parameters have been superseded anyway. Michael said we might want a few clarification statements, for example, Model Specific parameters are not expected to be Usage Info (since EDA tools aren't supposed to know what Model Specific parameters mean). Arpad said he had originally proposed such a restriction, but others had argued that it would stifle innovation if people couldn't distribute developmental models with special features. He noted that the result of those discussions was BIRD179, which had introduced a new Special_Param_Names parameter model makers should use to enumerate any Model Specific parameters that require special handling by an EDA tool (introduced in IBIS 7.0). MIPI C-phy support in IBIS: Arpad shared a work-in-progress "C-phy Overview for IBIS" to help spur discussion about whether IBIS should introduce changes to support C-phy. He reviewed a high-level diagram including 16 bit to 7 symbol mapping, parallel to serial conversion, symbol encoding for the 3-wire driver, and the elaborate state machine that controls the allowable transitions. Arpad noted that IBIS probably doesn't have to involve itself with most of this, and IBIS could focus on characterizing the analog buffer behaviors for the Tx and Rx triplets. He then focused on the analog buffer portion. He reviewed a diagram of an equivalent circuit for the 3-wire Tx. The buffers have a 50 Ohm impedance when driving high or low, and when driving the mid-state they have 100 Ohm impedances to high and low and effectively maintain a 50 Ohm impedance. Arpad said we could model this equivalent system in IBIS if we had 100 Ohm models in the [Model] and [Submodel] keywords. If they were driven in the same direction we would have a 50 Ohm pullup or pulldown, and if driven in the opposite directions we could duplicate the mid-state behavior. Arpad noted that there might be issues with the accuracy of the edge rates with this approach, depending on whether the two models drive in the same or opposite directions. This may involve issues with the way the C_comp compensation algorithm is implemented for the K(t) coefficient computations. Arpad said we might need new keywords or subparameters to define independent stimuli for the [Model] and [Submodel], but this would be a relatively simple change. Arpad discussed C-phy equalization. For the Tx, equalization is implemented by having 3 sublevels for each of the 3 output levels (e.g., for the high level, there are H2, H1, H0 sublevels), and only allowing certain transitions (e.g., when transitioning from high to low, for example, the transition occurs from any of the 3 high sublevels to only L2). Arpad said the Tx equalization is defined in terms of impedances for main and sub buffers, and it's difficult or impossible to associate a single equalization dB for all transitions. The equalization is defined in terms of Main and Sub buffer impedances, and Arpad reviewed a diagram of an equivalent circuit. Arpad noted that the Main and Sub buffers in this context are not the same as IBIS' [Model] and [Submodel]. Arpad said he was describing this so we can think about whether or how we would support this in regular I/V based IBIS or AMI. Arpad said that handling this Tx equalization with [Submodel]s would become more complicated, as we would have to add support for multiple [Submodel]s. He said we might be better off defining a more "native" IBIS approach and adding multiple sets of I/V and V/t tables to describe the buffers' impedance at each level and the transitions between the various levels. It might be better to introduce a new keyword for this instead of overloading the existing [Model] keyword. Yet another option would be to let model makers implement this in [External Model] using Verilog-A or VHDL-AMS. Arpad said the C-phy Rx has an optional 2-pole, 1-zero CTLE, and there is no DFE. He noted that his discussion is based on the 2019 version of the standard, and wondered if more equalization would be added in the future. The meeting ended before discussion of the overview was complete. Discussion will continue next week. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: None. ------------- Next meeting: 18 June 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives